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[57] ABSTRACT 

An electronic fund transfer (EFT) system capable of dis- 
playing a menu including one or more user-defined custom 
transactions associated with an identification card so that the 
user can select a desired transaction by a single selection or 
with limited inputs. The transactions may be defined by a 
user during a set-up/authorization operation and/or may be 
stored based on transactions performed by the user. Addi- 
tionally, the transactions may be stored on the identification 
card, in a local memory of a transaction terminal and/or in 
a system memory of the EFT system. A single identification 
card may be used to enable the user to select from a plurality 
of financial accounts with different institutions. 

21 Claims, 2 Drawing Sheets 
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ELECTRONIC FUND TRANSFER SYSTEM 
FIELD OF THE INVENTION 

The invention relates generally to electronic transaction 
network systems and more particularly to electronic fund 
transfer systems such as automated teller machines. 

BACKGROUND OF THE INVENTION 

Electronic fund transfer (EFT) systems in general are well 10 
known. One example of an EFT system is an automated 
teller machine (ATM). An example of an ATM is shown, for 
example, in U.S. Pat. Nos. 4,319,336 (the U.S. Pat. No. "336 
Patent) and U.S. Pat. No. 4,484,304, issued to Anderson et 
al. The general operation of ATMs is well known. Briefly, 
however, ATMs typically operate by a user inserting an ATM 
or other type of identification card into an ATM machine, 
entering a personal identification number (PIN), selecting an 
account (checking, savings, etc.), selecting a type of trans- 
action or function (withdrawal, deposit, transfer, payment, 
balance inquiry, etc.) and using individual numeric keys of 
a keypad to select the dollar (and cents) amount for the 
transaction. In some cases, the user also selects the language 
for the display (English, Spanish, etc.). The need to manu- 
ally enter or select each or many of these transaction 25 
parameters each time a user desires to perform a transaction 
can be annoying and time consuming. This is especially true 
for individuals who routinely perform transactions with the 
same or similar parameters. 

While certain ATMs enable a user to automatically select 
an amount (sometimes referred to as a "Fast Cash" amount) 
rather than entering the amount manually using the numbers 
of a keypad, a limited number of Fast Cash choices are 
available. Also, these choices are globally programmed in a 
system so that each user typically has the same limited 
choices. Moreover, even with a Fast Cash feature, the user 
still often needs to select certain transaction parameters such 
as an account (e.g., savings or checking) and a function or 
transaction type (e.g., withdraw cash). Only then are differ- 
ent dollar amounts displayed from which the user can 
choose. While this eliminates the need to enter specific 
dollar amounts, it still involves selection of several trans- 
action parameters or entries by a user. This is an undesirable 
drawback. 

EFT systems also include point-of-sale terminals and a 
number of other systems. Point-of-Sale (POS) terminals are 
used for example at grocery checkouts, gas station pumps 
and other retail locations to enable a user to pay for a 
purchase by using an ATM card, a credit card, a debit card 
or other similar methods. POS terminals also typically 
require a number of user inputs and transaction parameters 
to effect a transaction. 

Another problem that arises in using some EFT systems 
(e.g., ATM or POS terminals) is the need for separate user 
identification cards for each "account* 1 or institution with 
which a user has a financial relationship. Examples of such 
well known cards include bank ATM cards, American 
Express cards, MasterCard and Visa Cards, department store 
credit cards, gas company credit caids and air travel cards, 
to name but a few. Thus, many people typically cany one or 
more identification cards. This is inconvenient. Other draw- 
backs and disadvantages of the prior art also exist. 
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SUMMARY OF THE INVENTION 

It is an object of the present invention to overcome these 
and other drawbacks of the prior art. 
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It is another object of the present invention to provide an 
EFT system with a transaction menu customized for an 
individual user or account. 

It is another object of the invention to enable user-defined 
transactions to be completed with a reduced number of 
inputs from the user at the time the transaction is executed. 

It is another object of the invention to provide an EFT 
system which facilitates the selection of a greater number of 
menu choices. 

It is a further object of the invention to provide a single 
user identification card for use with an EFT system that 
enables a user to perform transactions involving a selected 
one or selected ones of the users accounts and/or selected 
financial institution(s) with which the user has a financial 
relationship. 

To accomplish these and other objects of the present 
invention, according to one embodiment of the present 
invention, an EFT system comprises an identification (ID) 
card, at least one central control unit connected to a plurality 
of transaction terminals, where each terminal preferably 
comprises a display, an ID card reader/writer, at least one 
user input device and a local controller. According to one 
aspect of the invention, the EFT system is operable to enable 
various transaction parameters for different transactions to 
be predefined by a user and stored before it is desired to 
effect a transaction, so that when it is desired to effect a 
transaction, the controller can cause an individually custom- 
ized menu to be displayed for each user to enable the user 
to select a user predefined transaction with a reduced num- 
ber of entries by the user at the time of execution of the 
transaction. 

According to one embodiment, one way to accomplish 
this is to store one or more customized user-defined trans- 
actions on a magnetic medium of the user ID card so that 
once a user inserts the ID card into a card reader at the 
terminal and enters valid verification data (e.g., a PIN), a 
menu containing choices corresponding to one or more of 
the user-defined transactions is displayed. Preferably, these 
transactions may be selected by touching a single key of a 
keypad, by touching an area of the display (e.g., if a touch 
sensitive screen is used), by touching a single key adjacent 
the menu entry, by using a "point-and-click" device or by 
other input methods. The user-defined transactions may be 
stored on the ID card upon activation, added by a user at a 
terminal or automatically stored based on the user's recent 
transactions. Alternatively, these transactions may be stored 
on the EFT system (foT example in a memory associated 
with a local controller of one or more terminals or in a 
central memory associated with one or more central con- 
trollers) and recalled at the lime a user desires to effect a 
transaction. 

According to another embodiment, the user may predefine 
and store a plurality of transactions involving different 
financial institutions. To facilitate this, a single ID card may 
be used to store the information. Thus, one universal card 
can be used by an individual to enable execution of trans- 
actions from or to a plurality of different accounts/institu- 
tions. 

According to other features and aspects of the invention, 
the user identification, transaction definition and/or selection 
of menu choices may be implemented, in whole or in part, 
by voice recognition. User identification may also be imple- 
mented, in whole or in part, by fingerprint verification. 
Selection of transaction information or menu choices may be 
implemented by a point- and -click device. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a perspective view of an EFT system according 
to one embodiment of the present invention. 

FIG. 2 is a flow chart illustrating operation of the present 5 
invention according to one embodiment of the present 
invention. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

Except as otherwise used in connection with a specific 
activity, the term "transaction 1 ' is intended to broadly 
describe a wide variety of activities that are or may be 
performed using an EFT system. By way of example, but 15 
without limitation, this includes withdrawing cash, travel- 
ers* checks, bonds, other negotiable instruments or other 
articles, depositing cash, checks, other negotiable instru- 
ments or other articles, transferring funds from one account 
to another, paying bills, credit card balances or loan pay- 20 
ments, cashing checks or other negotiable instruments, 
obtaining account balance information, paying for the pur- 
chase of goods or services, operating gaming devices (e.g., 
casino games, lottery games) and performing a wide variety 
of other activities. Typically, the execution of a transaction 25 
requires providing user identification information to the 
system, providing verification information to verify the user 
is an authorized user, selecting a type of transaction or 
function, and selecting one or more transaction parameters 
(e.g., accounts, dollar amounts, etc.) and causing the trans- 30 
action to be executed. 

With reference to FIG. 1, there is shown a transaction 
network system according to one embodiment of the inven- 
tion. The transaction network system preferably comprises 
one or more central control units or host processors 200, 35 
having associated database(s) or memories 300 and a plu- 
rality of transaction terminals 10 connected to one or more 
of the central control units 200 via communications link 400 
in a known manner. An example of one known system and 
communications link is described in the U.S. Pat. No. '336 40 
Patent. Other configurations may be used. 

Each terminal 10 preferably comprises or is connected to 
a local controller 11 that controls the operation of the 
terminal 10 and a local memory 12 associated with that local 45 
controller 11. The general structure and operation of these 
components in an EFT system, such as an ATM machine, is 
known. 

Each transaction terminal 10 preferably comprises at least 
one mechanism for identifying a user, for example, a card 50 
reader/writer 13. These terminals also comprise one or more 
input devices, such as a keypad 14 or selection keys 14a 
located adjacent a display 15. For some applications, such as 
an ATM, the terminal also preferably comprises one or more 
of a printer 16, a repository 17, a dispenser 18, a speaker 19, 33 
a microphone 20, and a fingerprint identification unit 21. A 
point-and-click device 22, such as a trackball or other 
similar device can also be provided to add novel function- 
ality to the ATM as described below. 

According to one embodiment, the transaction network 60 
system preferably is operable by use of user identification 
technique such as an identification (ID) card 30 unique to 
each user or account. Preferably the ID card comprises a 
plastic card having the ability to store information. As 
described elsewhere herein, other ID mechanisms may be 65 
used. For simplicity, various embodiments of the invention 
will be described with reference to an ID card having a 
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magnetic strip located thereon. For example, the card may 
comprise at least one magnetic strip for magnetically storing 
information. Information may be written to the card 30 and 
read from the card in a generally known manner. 

According to one aspect of the invention, the information 
stored on the ID card 30 may include one or more financial 
institution identifiers, one or more account identifiers, autho- 
rized user(s) identification information, including for 
example one or more personal identification numbers, and 
other desired information that is typically used on an ATM, 
debit, credit or other similar cards. The ID card 30 may also 
be used to store transaction information relating to user- 
defined transactions unique to the user or account. Prefer- 
ably, the stored information includes transaction identifier 
information sufficient to identify one or more particular 
transactions and/or transaction parameters and sufficient 
information associated with each such identifier to enable a 
desired transaction to be completed by selecting the trans- 
action identifier, with little or no additional input by the user 
at the time of execution. The transaction information is 
preferably individually selected by the card user and stored 
before executing a transaction to enable transactions to be 
more easily executed by a user and to enable the same (or 
similar) transactions to be performed multiple times without 
the need to re-enter all or most of the transaction parameters 
each time a user wants to execute a transaction. 

The information stored on the card may also include 
information that enables the controller to determine whether 
a printed record of an executed transaction should be printed 
by the printer 16 upon execution of a selected transaction. 
The information may be stored separately for each transac- 
tion or a global selection may be made for all transactions 
executed with the card. Upon execution of a selected trans- 
action, the controller caused the printer to print a record of 
the transaction if a printed record is primed. 

According to one embodiment, the transaction network 
system comprises an ATM system, wherein the user-defined 
transactions stored on ID card 30 may be read when a user 
accesses the ATM to enable the user to easily select a 
pre-deformed transaction for execution. TTiis may be done in 
a number of ways. Preferably, upon identification and veri- 
fication of a user, the controller uses the stored transaction 
information, along with general system information, to 
cause the display of one or more transaction menus custom- 
ized for the user. Preferably, the menu includes choices 
corresponding to one or more of the stored user-defined 
transactions. Other choices may be provided as discussed 
below. Preferably, the customized menu also will have a 
menu choice that enables the user to select a standard menu 
for that account and/or financial institution (e.g., a menu that 
enables a user to perform any transaction, not just the stored 
user-defined transactions, that may be ordinarily performed 
using the ATM). The term menu is intended to cover a single 
menu or a series of menus. 

Upon the user's selection of a desired menu choice, the 
associated transaction is then executed without the need for 
further inputs or selections by the user or with limited 
additional inputs or selections, thereby minimizing the num- 
ber of selections, inputs or entries required by a user to 
execute a desired transaction. 

For example, one transaction that a particular user may 
often perform is withdrawing $25 from a primary checking 
account. Therefore, upon insertion of the ID card 30 into the 
reader/writer 13, information stored on the ID card 30 is read 
(other preliminary steps may also be performed in a known 
manner, such as entering a PIN, etc.) and a number of menu 
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choices are displayed on the display 15, The user-custom- 
ized menu preferably comprises a display of at least some of 
the user-defined transactions, preferably including custom 
transactions (or custom transaction identifiers) CTl-CTN 
and an option to display a standard menu SM. Preferably, 
there is an alphanumeric (or other) identifier next to each 
menu item. For example, the first menu choice may be 
* "withdraw $25 from Primary Checking." The number "1" 
may appear next to this menu choice as a transaction 
identifier lb execute this transaction the user merely 
touches the "1" key on the keypad (and optionally hits 
"ENTER"). This selection is received by the controller 11 
which causes the selected transaction to be executed by the 
terminal and/or EFT system. This minimizes the number of 
selections/key entries a user must perform to execute a 
transaction. It also offers greater flexibility than systems 
which have "Fast Cash" or similar features where every user 
(or group of users) is offered the same limited transactions 
and which still usually require the user to select an account 
and often times a transaction function (e.g., withdraw cash) 
and an account before the "Fast Cash" choices are displayed, 
According to other embodiments, the information stored 
on the ID card or associated therewith may include infor- 
mation that is read by the card reader to enable the controller 
to determine whether the user/institution wants the user 
customized menu to be displayed automatically, not dis- 
played, or displayed as an option from the main menu. If it 
is determined that the customized menu is to be displayed 
automatically, then upon entry of the appropriate PIN, the 
controller causes the customized user menu to be displayed 
on the display. If it is determined that the customized menu 
is not to be displayed, then upon entry of the appropriate 
PIN, the controller causes the standard transaction menu to 
be displayed (to enable the user to use the normal ATM keys 
to define and execute a desired transaction.) If it is deter- 
mined that the customized menu is to be displayed as an 
option on the standard menu, then upon entry of die appro- 
priate PIN, the controller causes the transaction menu to be 
displayed with the standard transaction menu options (to 
enable the user to define and execute a desired transaction) 
and a customized menu option which if selected by the user 
causes the controller to display the customized menu. 
According to other embodiments of the invention, the sys- 
tem may store information which determines the particular 
account, account type or particular institution with which the 
account is related, and based on prestored information in the 
system (e.g., at the local and/or central controllers) deter- 
mines which type of menu is to be displayed to the particular 
user. 

FIG. 2 is a flow chart illustrating the operation of pre- 
ferred embodiments of the present invention. For purposes 
of this description, it is assumed that a user has already 
predefined one or more customized transactions and that this 
information is stored on the user's ID card (or in a memory 
of the EFT system), for example, during setup of the ID card. 
Other preliminary steps may also be performed if desired. 
Furthermore, for simplicity this embodiment will be 
described in connection with an ATM. However, it is to be 
understood that this embodiment and other features and 
embodiments described herein can be used with other types 
of EFT systems. Moreover, for simplicity, the well known 
steps associated with the local controller communicating 
with a central controller are omitted. 

In step 101 the user is identified. This may be accom- 
plished in a number of different ways, including by use of an 
ID card (e.g., ATM card), by entering an alphanumeric 
identifier using a keypad of the ATM terminal, by voice 
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recognition, fingerprint recognition, by other identification 
techniques, or a combination of the foregoing. Next, account 
information associated with the identified user is read (step 
102). Preferably, a verificadon step is performed to verify 
that the identified user is a valid user (step 103). This may 
be accomplished by prompting the user to enter a PIN or 
other identifier (for example, a fingerprint and/or by speak- 
ing a certain message) and having the controller determine 
if the identifier is a valid identifier for the user and/or 
account (step 104). If it is not, control may return to step 103 
for a retry or to step 101 to cancel the improper attempt. If 
the identifier is valid, control passes to step 105 (or in an 
alternative embodiment to step 105 A, as will be discussed 
below). Depending on whether all of the necessary infor- 
mation was read in step 102, it may be desirable to read other 
information from the card (or a memory of the EFT system) 
after the validation step (step 103). 

In step 105, according to one embodiment, the controller 
causes a custom menu for the user to be displayed. The 
custom menu preferably comprises choices (e.g. CTl-CTN 
of FIG. 1) for the user to select one or more transactions 
predefined by the user. Optionally, one menu item includes 
a choice for the user to select a "Standard Menu" (e.g. SM 
of FIG. 1). The Standard Menu preferably corresponds to the 
types of menu typically used with ATM systems. For 
example, the Standard Menu may list a number of choices 
of types of transactions or functions that may be performed 
(e.g., withdraw cash, deposit cash, transfer funds, balance 
inquiry, etc.) and prompt the user for other transaction 
parameters. In step 106, the user selects one of the displayed 
menu items. As discussed herein, a variety of different 
mechanisms may be used to select a displayed menu item. 
In step 107, the controller determines whether the selected 
menu choice is a request to perform a custom transaction. If 
the controller determines that a custom transaction was not 
requested in step 107, then according to one embodiment a 
Standard Menu is displayed (step 205). However, other 
alternatives may be used. If a custom transaction was 
requested in step 107, the controller causes the selected 
transaction to be performed (step 110). 

Depending on the type of transaction selected, the 
selected transaction may be performed without further 
action by the user. If the user defined custom transaction 
contains all of the necessary information, the controller can 
cause the transaction to be executed based on the stored 
information. Alternatively, the display may prompt the user 
to enter additional information (step 108), For example, if 
the user predefined transaction specifies a type of transaction 
and one or more accounts, but not the amount, the user may 
be prompted to enter the desired amount for the transaction. 
One advantage of this technique, for example, is where each 
month a user pays his American Express card balance from 
his primary checking account. The user could set up a 
custom transaction that stores information to pay an amount 
(to be entered) from primary checking to that user's Ameri- 
can Express account. Then, all the user needs to do to 
execute this transaction, is to select this custom transaction 
and enter the amount for that month. Numerous other 
examples will be readily apparent. 

Also, it may be desirable after selection by the user of a 
custom transaction (step 107), and/or additional input (step 

108) that the controller causes the transaction type and 
parameters to be displayed with a prompt for the user to 
verify that this is the desired transaction to be executed (step 

109) . If the transaction type and parameters are as desired, 
the user may verify this by one of the input techniques 
described herein or other input techniques. Preferably, the 
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display produced in step 109 may also give the user options 
to cancel the transaction, edit the parameters thereof, rcse- 
lect a transaction or other desired options. 

After the desired transaction is processed (step 110), the 
controller preferably causes ihe display to display the option 
for the user to select another transaction or to finish the 
session. Jn step 111, if the controller determines that the user 
desires another transaction, control returns to the point after 
step 104. If not, control returns to Stan. 

Reluming to step 205, in response to a Standard Menu 
being displayed, (he user is prompted to select a function or 
transaction (step 206), an account from which the transac- 
tion should be processed (step 207), if necessary a "to- 
accounf (step 208), i.e., an account to which the transaction 
should be processed, for example, if the transaction is a 
transfer of funds from one account to another, and an amount 
(step 209). Depending on the type of transaction, other 
parameters may be selected. Steps 108 and 109 also may be 
performed if desired. Once all of the necessary transaction 
information is selected and any verification has occurred, 
then control passes to step 110 and the transaction is 
processed. The standard menu may also prompt the user for 
information in an order different than specified above and/or 
for different information. 

According to another embodiment, after the validation 
procedure is performed (step 104), control passes to step 
105A. According to one embodiment, step 105 A causes a 
user prompt to be displayed which asks the user if the 
custom menu is to be displayed or whether a Standard Menu 
should be displayed. If the user selects the custom menu to 
be displayed, control passes to step 105. If not, according to 
one embodiment, the Standard Menu is displayed (step 205), 
According to another embodiment, the user may be 
prompted to indicate whether a menu (similar to the Stan- 
dard Menu) should be displayed with one of the menu 
options being the choice of having the custom menu dis- 
played. In step 220, the controller determines whether the 
custom menu option is selected. If not, then the Standard 
Menu is displayed (step 205). If yes, control passes to step 
221 whereby a standard menu with a custom menu display 
option is displayed. After selection of a menu choice by a 
user (step 222), the controller determines if the custom menu 
option is selected (step 223). If yes, a custom menu is 
displayed (step 105). If not, the user selects a function from 
the Standard Menu (step 206). 

Alternatively, instead of the user selecting whether a 
particular menu should be displayed, this information may 
be determined by the EFT system or ATM terminal. For 
example, for some ATM terminals, it may be decided as a 
system choice that one or another menu will be displayed, 
Alternatively, the choice of menu may be dictated by the 
particular user (based on certain user information) or the 
type of account determined in step 102, or by the financial 
institution with which the account is held. For example, 
some financial institutions may choose that a particular 
menu will be displayed. Alternatively, the menu to be 
displayed may be pre-selected by the user and information 
corresponding to the selected menu can be stored on the 
user's ID card, in one or more local memories of one or more 
ATM terminals, or in one or more central memories of the 
EFT system. 

Consistent with the foregoing, instead of or in addition to 
storing user-defined transaction information on the ID card, 
such information may be stored in the local memory of one 
or more terminals or in a central memory or memories of the 
system. Storage of such information in a local memory may 
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be particularly useful where a user frequents a particular 
terminal such as a local bank ATM or grocery store or where 
the 'terminal" is uniquely associated with a particular user 
or group of users, such as when the terminal comprises a 
home computer, a portable terminal or other such equip- 
ment. 

According to another feature of the present invention, if 
a user executes a transaction that is not already stored (on the 
ID card, locally in the terminal or globally in the system), 
upon completion of the transaction, the card reader/ writer 
may write the transaction information to the card (or local 
memory of the terminal and/or central memory of the 
network). If written to the ID card for example, the trans- 
action may be stored as a "Recent Transaction." According 
to one embodiment of the invention, one or more Recent 
Transactions options may be displayed on the customized 
user menu. Alternatively, a menu option may be "Display 
Recent Transactions." The input mechanism may be 
designed to facilitate scrolling through recent transactions. 
For example, up/down keys may be provided. Alternatively, 
according to one aspect of the invention a point-and-click 
device (e.g. a trackball) may be used as further described 
below. The use of a point-and-click device is especially 
advantageous if it is desired to provide menus with a 
relatively large number of choices to facilitate scrolling 
through pages of the memory and pointing to one of the 
choices. Other advantages of using a point-and-click device 
also exist. 

According to another feature, after the user executes a 
transaction that is not already stored on the ID card, a prompt 
may be displayed to ask the user if the transaction should be 
stored as a transaction to appear on the customized menu. If 
the user desires to do so, the transaction information may be 
stored as a new user-defined transaction on the ID card. 
Alternatively, or in addition to this, the user customized 
menu may include an option to enable the user to change the 
stored transactions. This preferably includes the ability to 
modify or delete an existing stored transaction and the 
ability to add a new transaction. 

The features of the invention may be used in a variety of 
electronic transaction systems including ATMs, POS termi- 
nals (e.g. supermarket or retailer checkouts, gas pumps, 
etc.), travelers check dispensers, coupon dispensers, gaming 
devices (e.g., slot machines or other "casino games"), lottery 
machines, check cashing machines, etc. 

By way of example, if used in connection with a POS 
terminal, the terminal may be connected with a cash register 
or other device to indicate to the terminal the amount of a 
transaction. TTie user-defined transactions may include 
transactions such as "pay amount by ATM" or "pay amount 
by VISA." Other predefined transaction options could 
include "Pay by ATM and Receive $50 Cash Back" or "Pay 
by ATM and Receive Cash Back." In this latter example, one 
or more transaction parameters may be entered by the user 
at the time of use (e.g., the amount of cash to receive back). 
At gas pumps, the user may pre store selections such as the 
type of gas desired (regular, premium, etc.) and whether or 
not a receipt should be printed upon completion of the 
transaction. 

According to another embodiment of the present inven- 
tion, the ID card may be used as a "universal" card to avoid 
the need for a user to carry a number of different ID cards 
such as ATM cards and/or credit or debit cards. According 
to this embodiment, information for a plurality of accounts 
may be stored on a single card. The user customized menu 
may include transactions for a plurality of different accounts 
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and/or financial institutions. For example, a universal card 
may have information stored thereon for a user's VISA 
card(s), American Express card(s), department store card(s), 
casino card(s), gasoline credit card(s) and one or more bank 
ATM cards. The card may store information to enable a user 5 
to execute one or more transactions with one or more 
selected institutions with which the user has a relationship or 
is authorized to transact with. For some institutions, the user 
may have more than one account. All of the information 
necessary to enable the user to perform a transaction may be Q 
stored on a single card. If this feature is used, the stored 
transaction information may include the user-defined trans- 
action information identified above along with an identifier 
of the institution and the desired account for which the 
transaction should be performed. For example, such a stored 
transaction may include a transaction to 'Take $25 Cash 15 
Advance from Visa Card" or "Pay $25 From Bank Checking 
To Visa.'* 

According to one embodiment, it may be desirable to 
store only most of the transaction information necessary to ^ 
execute a transaction. For example, the stored partial trans- 
action may be "Pay Visa From Checking." Then, upon 
display of this item on the user customized menu and 
selection of it by a user, the user may be prompted to enter 
the amount to be paid. This option is generally useful when ^ 
aspects of a particular transaction may vary but some or all 
of the transaction is repeated. The institution/account infor- 
mation for this embodiment may be written to the ID card in 
a known manner and can be formatted in a convenient way. 
For example, the card may contain an institution with the ^ 
institution(s) and user-defined transaction information asso- 
ciated with one or more accounts. According to this embodi- 
ment, the user may insert the ID card into a terminal, and 
upon verification, a customized menu may be displayed. 
According to one embodiment, the menu may include 35 
options for performing transactions with a number of dif- 
ferent institutions/accounts. Alternatively, the user may 
select an institution and a customized menu for that insti- 
tution may be displayed as described above. If a universal 
card is used at a POS terminal, the user customized menu ^ 
may display the list of institution accounts that the particular 
user may chose from. Then the user may select the account 
from the menu that is to be used for the transaction. This 
offers more flexibility and efficiency than currently used 
systems. A point-and-click device may be used to scroll 45 
through the choices and select an institution. 

According to another feature, after a customized menu is 
displayed and a user selects one of the transaction options 
from the menu, a more detailed description of the transaction 
may be displayed to enable the user to verify the desired 50 
transaction. For example, the transaction type and transac- 
tion parameters may be displayed. 

While many of the general systems components for an 
ATM and their functions are known, various other compo- 
nents may be particularly useful with various aspects of the 55 
present invention. For example, the user identification step 
may be accomplished in a number of ways. For example, the 
user may be identified by a user identification card unique to 
each user (or account), by voice recognition, entry of 
alpha- numeric information by a keypad or similar input 60 
mechanism, by fingerprint recognition or a combination of 
these or other techniques. For example, if a fingerprint (or 
voice) identification unit is provided at each (or some) 
terminals, the user may be identified by simply entering an 
appropriate finger into the fingerprint identification unii (or 65 
speaking into the voice identification unit), whereby the unit 
then reads the input information and compares this read 
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information 10 previously stored identification information 
to determine the identify of the user. The stored information 
may be accumulated in the local memory and/or central 
memory. To facilitate this, each user may be required to 
provide the necessary fingerprint (or voice) identification 
information at the time of activation of an account (or at 
other convenient times). According to one embodiment, the 
identification information may be initially stored in a central 
memory. A potential adversity to this approach however is 
that with a large number of authorized users, it may take 
some time to find a match between input identification 
information and stored information. An alternative is to store 
such information in a local memory of each terminal through 
which the user accesses the system, as such accesses occur. 
This would thus build up a local memory capability for each 
terminal that the user accesses. The local memories are 
likely to contain a lower number of user's information. If 
this approach is used, when the user enters the physical user 
identification information (e.g. voice or fingerprint), the 
local memory of the terminal through which the user is 
accessing the system can be checked first to find a match 
with prestored information. If a match is found, it is likely 
to occur in less time than if the central system memory is 
used to find such a match due to the relative number of 
individual's information stored in the respective memories. 
If the user has never used the particular terminal before, then 
no match will be found in the local memory and upon that 
determination, the local controller may cause a search of the 
central memory to occur. 

According to another aspect of this embodiment, an 
institution (e.g. a bank) having multiple terminals, may 
download user identification information to each of its 
terminals so that the user can rapidly access they system via 
any of that institutions terminals since the user's identifica- 
tion information (e.g. voice or fingerprint) will be stored 
locally in each of that institution's terminals. 

This or similar identification techniques could avoid the 
need for a user to carry an identification card. If no card is 
used, once the user is identified (or before), the user may 
enter institution information to identify an institution with 
which the user is identified. This may be accomplished by 
entering (e.g., via a keypad) an institution identification 
code, selecting an institution from a menu (or group of 
menus) that is (are) displayed based on information stored in 
the EFT system or by storing such information in the system 
(locally and/or centrally) in association with user identifi- 
cation. Once the user and account is identified, then verifi- 
cation information may be entered (e.g., a PIN) for the user 
for the selected institution or account and transactions may 
be selected as described herein. 

According to another embodiment of the invention, a 
publicly accessible ATM (or other EFT) terminal is provided 
with a point-and-click device such as a trackball or similar 
device to facilitate (and enhance) selection and/or input of 
desired transactions, functions, parameters,. menus or other 
choices. The use of such a pointing device can facilitate a 
number of other features. For example, with the use of such 
a device, a user may point to a menu item and click on it 10 
select it or double click on it for execution. Alternatively or 
in addition thereto, the device may be used to select a 
"custom transaction" menu option which causes a controller 
to display a list of predefined transactions to be displayed, in 
one or more columns, to enable one of the predefined 
transactions to be selected. Further, the list may extend for 
more than one page of the display and the device can be used 
to scroll up, down, left or right through the list and to select 
the desired transaction for execution. According to this 
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embodiment, the point and click device is operative] y con- 
nected to the terminal in a user accessible location. The 
movement of the pointing device by a user can then cause a 
cursor (or similar identifier) on the display to be moved to 
a desired position on the display to enable menu transaction 5 
items or parameters to be selected in a known manner. 

The user-defined transactions may be stored on the ATM 
card upon activation of the ID card, added by a user or 
automatically stored based on the user's recent transactions 
(e.g., by writing some or all of the transaction parameters to } q 
the ID card after a user manually enters a transaction and 
displaying this transaction as a menu choice the next time 
the user accesses the system). Alternatively, these transac- 
tions may be stored in a local memory of a terminal (e.g., a 
terminal of an ATM system) and be recalled when a user j 5 
desires to execute a transaction. According to this embodi- 
ment, the transactions may be stored in a local memory of 
one or more terminals or in a central memory of the EFT 
system. 

According to one embodiment, the transaction identifier 20 
and corresponding transaction information is stored on the 
ID card. Preferably, information corresponding to one or 
more transactions is stored. If desired, one card may be used 
to store information for more than one account for a single 
user. These multiple accounts may be with one or more 25 
institutions or entities with which the user is associated. 
Therefore, separate pluralities of user-defined transactions 
may be stored for separate accounts. For example, if a 
magnetic card is used, the transaction information for a 
particular account at a particular financial (or other) insti- 30 
tution may be stored on one (or more) magnetic strip(s) on 
the ID card. Each transaction preferably is stored with a 
transaction identifier and all or most of the information 
necessary to complete a transaction. If a universal card is 
used, the user may be first prompted to select the account/ 35 
institution with which a transaction is to be executed. Then, 
the custom transaction for that account/institution may be 
displayed (along with other choices as described herein). 

The controller may be any generally known controller 
capable of use with an EFT system. It may be programmed 40 
to cause operation in the manner described herein. 

The various inputs and selections described herein may be 
accomplished by the touch of a single key (or combination 
of keys) of the keypad, by touching a designated area of the 
display (e.g., if a touch sensitive screen is used), by touching 45 
a single input key adjacent to the transaction identified, by 
use of a "point-and-click" device associated with the termi- 
nal or by other input methods. In various circumstances, one 
or more of these types of input mechanisms may be advan- 
tageous over another. 50 

The ID card, if used, may comprise a magnetic card, a 
bankbook with a magnetic storage member, an EEPROM 
card, a "smart card", an 1C card or other suitable devices 
capable of storing the necessary information. 55 

Preferably, one or more user-defined transactions stored 
on the ID card 30 arc read by the card reader/writer 11 after 
the user inserts the card into the card reader/writer 11. The 
information may be read before and/or after the user enters 
verification data (e.g.,. a personal identification number or ^ 
PIN). The stored information may be read once and stored 
in a local memory of the ATM terminal or read from the card 
30 as and when needed, if the card is retained in the card 
reader writer 11 during use. 

If the card reader retains the card during use, upon 65 
insertion of the card into the card reader or upon selection of 
the transaction identifier, the corresponding transaction 
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information may be read from the card and used to execute 
the selected transaction. If a "dip" or "swipe" card reader is 
used, whereby the card is entered and withdrawn before 
selecting a transaction or passed through an external reader 
(i.e., it is not retained in the card reader during execution of 
a transaction), then the stored transaction information may 
be read and stored in a local memory of the terminal so that 
upon selection of a transaction identifier by the user, the 
corresponding transaction information may be read from the 
local memory and used to execute the selected transaction. 
If desired, this tatter method may be used even if the card is 
retained in the reader during use. 

The foregoing is a description of various aspects of the 
preferred embodiments and features of the present inven- 
tion. However, the invention is not so limited. Various other 
alternatives consistent with the invention will be apparent to 
one of ordinary skill in the art. The scope of the invention is 
only limited by the claims appended hereto. 

I claim: 

1. An automated teller machine system for use by a 
plurality of users comprising: 

user identification cards unique to each user and having 
information stored thereon including transaction infor- 
mation corresponding to custom transactions pre- 
defined by the user of the identification card; 

at least one user accessible transaction terminal compris- 
ing: 

card reader means for reading information stored on the 

user's identification card; 
display means for displaying a user customized menu 

comprising one or more of the custom transactions 

based on information read from the user's identification 

card; 

input means for enabling the user to select a custom 
transaction from the customized menu for execution; 
and 

control means for executing a selected transaction. 

2. The system of claim 1, wherein in response to the user 
customized menu being displayed, the control means causes 
the input means to be operable to enable the user to select a 
transaction by touching one of: i) a single key located 
adjacent to the displayed custom transaction; ii) an area of 
the display means; and iii) a key of a keypad operatively 
connected to the control means. 

3. The automated teller machine system of claim 1, 
wherein the input means comprises a point-and-click device. 

4. The automated teller machine system of claim 1, 
wherein the user customized menu comprises a plurality of 
choices including user defined transactions choices and at 
least one standard menu choice. 

5. The automated teller machine system of claim 1, 
wherein a single user identification card stores information 
for a plurality of institutions with which a user of the 
identification card has a financial relationship. 

6. The automated teller machine system of claim 1, 
wherein the control means enables the user to select from a 
plurality of user customized menus based on information 
read from the user's identification card, 

7. The automated teller machine system of claim 1, 
wherein the selection of a custom transaction from the user 
customized menu enables execution of a custom transaction 
without further inputs by the user. 

8. The automated teller machine system of claim 1, 
wherein upon selection of a custom transaction, the control- 
ler causes the transaction parameters to be displayed on the 
display means to permit verification by the user. 
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9. The automated teller machine system of claim 1, 
wherein the stored transaction information comprises some, 
but not all of the transaction parameters necessary to define 
and execute custom transaction, and upon selection of such 

a custom transaction by the user, the controller causes a 5 
prompt to be displayed on the display means to prompt the 
user to input additional information necessary to enable the 
selected transaction to be executed. 

10. The automated teller machine system of claim 1, 
wherein the transaction terminal further comprises a printer, 10 
and the stored transaction information includes information 
that enables the controller to determine whether a printed 
record of an executed transaction should be printed upon 
execution of the transaction. 

11. In an automated teller machine system comprising a 15 
central controller having an associated control system 
memory, and at least one transaction terminal comprising an 
input, a display, a controller, a local memory and an iden- 
tification card reader, a method of executing a user-defined 
transaction comprising the steps of: 20 

(a) storing user-defined custom transaction information on 
the identification card; 

(b) entering an identification card into the identification 
card reader; 

(c) reading information stored on the identification card, 
including user-defined transaction information stored 
on the identification card; 

(d) displaying a customized menu including a plurality of 
user-defined transactions based on information read 30 
from the identification card; 

(e) selecting one of the displayed transactions; and 
(0 executing the transaction selected in step (e). 

12. The method of claim 11 wherein the step of selecting 
comprises touching one of: i) a single key; ii) touching an 35 
area of the display; iii) touching a key of a keypad opera- 
tive! y connected to the controller; iv) operating a point-and- 
click device. 

13. The method of claim 11 further comprising the step of: 
storing, before entering the identification card into the 40 

card reader, information corresponding to one or more 
user-defined transactions on one of the identification 
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card, a local memory associated with the terminal and 
a central system memory. 

14. The method of claim 11 further comprising the step of 
storing information corresponding to at least one of said 
transactions on said identification card based on a recent 
transaction performed with the identification card. 

15. The method of claim 11 wherein the step of displaying 
a customized menu comprises displaying a plurality of 
choices for executing user defined custom transactions and 
at least one choice of displaying a different menu. 

16. The method of claim 11 wherein the step of storing 
comprises storing a plurality of user defined custom trans- 
actions for a plurality of institutions with which the user of 
the identification card has a financial relationship. 

17. The method of claim 11 further comprising the step 
the user selecting from one of a plurality of user customized 
menus for display on the display. 

18. The method of claim 11 wherein upon selection of a 
displayed transaction, the transaction is executed without 
further input by the user. 

19. The method of claim 11 wherein after performance of 
the selecting step, the controller causes the transaction 
parameters associated with the selected transaction to be 
displayed for verification by the user. 

20. The method of claim 11 wherein the information 
stored in step (a) comprises some, but not all, of the 
transaction parameters necessary to execute a custom trans- 
action, and after the selecting step (step (c)), the controller 
causes a prompt to be displayed on the display to prompt the 
user to input additional information necessary to enable the 
selected transaction to be executed; and further comprising 
the step of entering additional information to enable the 
selected transaction to be executed. 

21. The method of claim 11 wherein the transaction 
terminal further comprises a pointer, and further wherein 
step (a) comprises storing information that enables the 
controller to determine whether a printed record of an 
executed transaction should be printed upon execution of the 
transaction; and after step (f), determining whether a printed 
record of the executed transaction should be printed. 



02/10/2004, EAST 



version: 1.4.1 



